Self describing capabilities are a well known mechanism for enforcing access control. In practice, capabilities mechanisms usually involve three parties. First, there is a client who wants access to a certain shared resource. Next, there is a security/policy manager who provides the client with a credential, which enables the client to access the shared resource. The credential is often a cryptographically hardened capability. The capability encodes the access rights of the client to the shared resource and is usually derived from a predefined policy. Finally, there is an enforcement point, or security access point. The client's access to the shared resource is through the security access point, which validates the capability of the client and either permits or denies access to the resource. The validation process usually involves a secret key that is shared between the security manager and the security access point.
Although useful, capabilities mechanisms suffer a practical problem. Managing the access control of many clients to many shared resources might be too much for a single security manager or administrator. Too many clients and resources overburden the security manager and results in bottlenecks. In terms of the number of keys that need to be maintained, both the security manager and the security access point must share a secret in the form of a unique key for each shared resource for increased security. In terms of hardware, tremendous amounts of resources (e.g., RAM and data storage) are required for maintaining these keys and the policies related to individual clients and resources. Further, tremendous amounts of network bandwidth is required to support client connections to obtain credentials and to access the resources via the security access point.
There have been proposals to address these issues; however, none of the proposals offer viable solutions. For example, Block-Level Security for Network-Attached Disks introduces the idea of capability groups, which reduces the load on a security manager by limiting the number of capabilities that can be revoked at once. See M. K. Aguilera et al., “Block-Level Security for Network-Attached Disks,” Proc. 2nd USENIX Conference on File and Storage Technologies, 2003. However, this proposed mechanism is targeted to block devices and is not applicable to general purpose self describing capabilities mechanisms. Next, Scalable Security for Large, High Performance Storage Systems introduces several methods for reducing the load on the security manager. See A. W. Leung et al., “Scalable Security for Large, High Performance Storage Systems,” StorageSS '06: Proceedings of the second ACM workshop on Storage security and survivability, ACM Press. At the heart of these methods is the assumption that many shared resources and clients can be grouped to represent a higher level logical entity to which capabilities are granted. However, this assumption is not valid for generally shared resources. Particularly, this proposal does not address managing the numerous permission policies affecting individual user access to shared resources. One underlying limitation of both proposals is that they both rely on the idea that a single security administrator must manage all the clients and resources.